Cellular communications have continuously evolved from early days of GSM (Global System for Mobile Communications) networks to GPRS (General Packet Radio Service) and further to UMTS (Universal Mobile Telecommunications System) which is currently used worldwide. Next-generation LTE (Long Term Evolution) networks are expected to be available in the near future. Services provided by cellular communication networks have also been developed along with access technologies. Current cellular networks provide not only basic voice communication services but also transmission of short text messages and access to the global Internet. Recently, cellular networks have been extended to provide new services for covering non-human communication such as machine-to-machine (M2M) communication. 3GPP (Third Generation Partnership Project) has started to define requirements for supporting machine type communication by cellular networks (see Non-patent Document 1 listed below). This enables cellular networks to support machine type communication more appropriately.
M2M communication is a communication paradigm different from human-to-human (H2H) communication. M2M communication differs in communication scenario and communication model. Most machine type communication scenarios relate to communication between one or more MTC (Machine Type Communication) devices and one MTC server. Examples of a scenario in which an MTC device communicates with an MTC server include the following a) to g): a) a health care industry in which an MTC device updates human health-related data to an MTC server; b) route tracking in which a ship belonging to a company is tracked by a server using updated data sent from a moving ship equipped with an MTC device; c) an industry of monitoring possessions; d) a weather sensor for updating weather-related information to a server; e) a food sensor for updating food condition-related information to a server; f) a home smart meter for updating power outage or consumption-related information to an MTC server; and g) a surveillance camera for updating intruder detection information to an MTC server.
In addition to a scenario in which an MTC server communicates with an MTC server, there is also another MTC communication scenario such as communication between MTC devices. An example of such a communication scenario is that communication is performed between smart meters installed in a house, in order to control the MTC devices to improve operations. M2M communication has the following features different from H2H communication: a) operating without human involvement or determination process; b) having different communication traffic types such as data applications which have very low delay tolerance; c) having different communication models such as a type in which only mobile devices are present, a model in which polling is performed from a server for data acquisition, and a typical mobile type; d) having different mobility patterns to perform different location management operations on MTC devices such as a low mobility pattern and a non-mobility pattern; e) having different addressing mechanisms such as group-based addressing that enables a plurality of MTC devices to be reached using a single message; f) having a need to prevent theft or vandalism by MTC devices which are not human-controlled; g) having group-based charging and service provision models by a plurality of MTC devices placed under subscription of a service; and h) operating with minimum power consumption by making most MTC devices battery-driven without supply of power lines for less expensive operations. Such unique features specifically concerning M2M are used to specify service requirements and achieve network optimization. As the number of MTC devices connected to a 3GPP core network is much larger than the number of conventional user terminals (UEs) connected to 3GPP, network optimization targeting for the unique features of machine type communication is essential. This allows network operators to significantly reduce operation costs and provide attractive charging models for MTC devices.
Standardization has been made by the SA1 (Service & System Aspects 1) and SA2 (Service & System Aspects 2) working groups of 3GPP, to propose service and architecture requirements for providing network optimization specifically implemented with regard to the unique features of MTC devices. Service requirements and network optimization related to MTC devices are disclosed, for example, in Non-patent Document 1 listed below. Many of the MTC-related service requirements disclosed in Non-patent Document 1 are intended to optimize or improve networks for MTC communication. Non-patent Document 1 discloses a service requirement that a bandwidth upper limit is imposed on a group of MTC devices that belong to a single subscriber and communicate with an MTC server. Such a group bandwidth upper limit is hereafter referred to as a group aggregate maximum bit rate (group bandwidth maximum bit rate, G-AMBR). In Non-patent Document 1, all parameters about bandwidths are expressed in bits per second. The G-AMBR can be assigned independently for an uplink (UL) and/or a downlink (DL). An uplink G-AMBR is referred to as a UL-G-AMBR, and a downlink G-AMBR is referred to as a DL-G-AMBR. Only the UL-G-AMBR may be applied in an M2M group communication model in which user plane (U plane) traffic is mainly an uplink. Likewise, only the DL-G-AMBR may be applied in the case where a downlink is dominant. In the case where the G-AMBR is applied, a total bandwidth for user plane traffic by a large number of MTC devices belonging to the group can never exceed the G-AMBR When this group upper limit is exceeded, traffic shaping is performed at an enforcement point (bandwidth use status check point). In the above-mentioned group-based communication model, all MTC devices communicate with the same server and accordingly all MTC devices use the same packet data network gateway (P-GW), so that the traffic enforcement point is the P-GW. A primary motivation for assigning the G-AMBR is to set a smaller G-AMBR than a total bandwidth required when all MTC devices in the group simultaneously use the core network.
It is reasonable to assign the G-AMBR upper limit by the network in group-based communication. The use of the tightened group bandwidth upper limit contributes to lower service charges paid by the subscriber to the operator. Moreover, the operator can accommodate many MTC devices in the network, and earn more income by offering attractive prices. Typically, the G-AMBR is a static value assigned by a home subscription server (HSS), is statically stored in the P-GW, or provided from a policy control and charging related function (PCRF) to the P-GW by a static method. However, the G-AMBR may be a dynamic value dynamically manageable by the PCRF. Functional roles of the above-mentioned functional entities are described in detail in Non-patent Document 2 listed below.
By employing the concept of the G-AMBR, many advantages can be provided as described above. However, there are also tradeoffs, i.e. disadvantages. For example, due to the G-AMBR upper limit, a problem arises in the case where the bandwidth currently used among a plurality of MTC devices in the group has reached the G-AMBR but another MTC device in the group tries to send user plane traffic. Here, due to the G-AMBR upper limit, a problem also arises in the case where a plurality of MTC devices simultaneously seek a limitedly available bandwidth or a freely available bandwidth. The free bandwidth available in the group (hereafter denoted as AvGrBW) is equal to “(G-AMBR)−(current sum total of bandwidths or bit rates for MTC devices in the group sending U plane traffic)”. The AvGrBW can be expressed in bits per second.
As summarized in Non-patent Document 2, according to normal UE operations, a QoS (Quality of Service) parameter associated with a default bearer is notified from a mobility management entity (MME) to a UE by a NAS (Non Access Stratum) message (Attach Accept message) during an initial attach procedure. In addition to a normal UE-directed bearer context notification procedure during the initial attach procedure, bearer context modification is notified to the UE using a bearer modification procedure when the UE is in a connected mode or an idle mode. The connected mode and the idle mode are defined in Non-patent Document 2. The bearer modification procedure can be triggered by the P-GW in most cases, but may also be triggered by the MME. It is clear from the above description of the normal UE procedures that the UE needs to recognize the bearer context beforehand and can thereby send uplink U plane traffic having appropriate properties and receive downlink U plane traffic. Besides, resource management and 3GPP EPS (Evolved Packet System) QoS models are not violated. For example, in the case where the network assigns a parameter related to a bandwidth to a bearer (e.g. dedicated bearer (individual bearer)), the UE needs to adjust the transmission rate of U plane traffic accordingly. In the case where the network assigns a maximum bandwidth (UE-AMBR) for all non-GBR (Guaranteed Bit Rate) flows of the UE or a maximum bandwidth (APN-AMBR) for all non-GBR flows of an access point name (APN) of the UE, the UE needs to ensure that the sum total of the bandwidths of the flows does not exceed the network-imposed upper limit. As an important advantage of recognizing the bearer properties beforehand, there is also an advantage that U plane traffic transmission can be speedily started when the UE transitions from the idle mode to the connected mode. This saves the wait time for the UE to recognize the bearer context before sending U plane traffic.
Bearer-related QoS parameters are, for example, QCI (Quality Class Indication), ARP (Allocation and Retention Priority), MBR (Maximum Bit Rate), GBR (Guaranteed Bit Rate), and the like. In addition to such QoS parameters, group QoS parameters for non-GBR bearers such as the UE-AMBR and the APN-AMBR are also assigned. Detailed description and definition of these QoS parameters are explicitly disclosed in Non-patent Document 2. A minimum necessary default bearer is created for every PDN (Packet Data Network) connection. The default bearer is assigned a minimum QoS parameter (QCI value needing a minimum QoS procedure). This bearer is normally a non-GBR bearer. Since the QoS parameters MBR and GBR relate only to GBR bearers, the QoS parameters MBR and GBR are not assigned to the default bearer. Moreover, a dedicated bearer is normally created by a P-GW initiated create bearer request procedure, as disclosed in Non-patent Document 2. The dedicated bearer may be a GBR bearer or a non-GBR bearer. When the dedicated bearer which is a GBR bearer is assigned by the network, the network guarantees the bit rate of the GBR bearer by using an appropriate resource reservation procedure in the radio access network (RAN) and the core network.
The network guarantees the bandwidth for the dedicated bearer but, in such a case where resources are unavailable, can always modify the GBR of the dedicated bearer. In current UE procedures, this dedicated bearer modification hardly occurs, and the dedicated bearer modification is notified to the UE beforehand. Likewise, the UE-AMBR and the APN-AMBR of the UE are hardly modified, and it is assumed that such information can be notified to the UE using a bearer modification procedure without QoS modification as described in Non-patent Document 2. For example, when the UE is in the idle mode, the bearer context modification is notified by initial paging, according to which the UE executes a service request procedure. Once the UE has succeeded in executing the service request, the modified bearer context is provided to the UE. However, since current UEs do not have low power requirements like MTC devices, no serious problem of power consumption arises even when paged and activated to receive the bearer modification. Besides, for normal UEs, the network has almost no need to concern about resource management. Since the bearer modification hardly occurs, the costs of paging and signaling associated with the paging are not very high. For example, the possibility that the UE-AMBR, the APN-AMBR, or the GBR for the dedicated bearer is modified is low. Regarding MTC devices, however, given that a large number of MTC devices are present, the network sends more bearer modification messages when there is a group bandwidth upper limit or a special technique for efficient resource management (technique employed in the network to accommodate M2M communication that requires an extremely large number of MTC device connections).
Patent Document 1 listed below discloses a method of reassigning a bandwidth from a first device to a second device in the case where the first device does not use the bandwidth. It is assumed here that the devices perform group communication. Patent Document 1 also discloses a method of achieving efficient bandwidth use by transferring a bandwidth which is not used in one device to another device.
Patent Document 2 listed below discloses a method of realizing a communication mechanism of a group communication model that allows only one device in a group to perform communication. In this method, a priority mechanism is covered by a method of using priority in initial access control. Interrupt priority for obtaining a higher priority device to be served is covered, too.
Patent Document 3 listed below discloses a method whereby communication priority is assigned to a terminal by an authentication server upon attachment. It is assumed that the assigned communication priority is notified from the authentication server to a router, and also the communication priority is appended to a packet sent from the terminal. Upon detecting the packet to which the communication priority is appended, the router processes the packet by a special method. The router also performs access control of a high priority terminal based on communication priority.
Patent Document 4 listed below discloses a method of appropriately addressing group devices. A transport network includes a flexible topology for internally defining transport elements. The transport elements each include a port group having a plurality of geographically distributed ports from the transport network. Point-to-multipoint connectivity is defined between the ports in a port group. An identifier represents the port group as a single element to internal and/or external elements for protocol exchanges.